6.17.1. Instalación de GCC
Al igual que en Section 5.10, “GCC-4.8.2
- Pass 2”, ejecute el comando sed para forzar al compilador a usar
-fomit-frame-pointer
con el fin de garantizar un compilador compatible.
case `uname -m` in
i?86) sed -i 's/^T_CFLAGS =$/& -fomit-frame-pointer/' gcc/Makefile.in ;;
esac
También corrige un error en uno de los Makefiles de verificación y desactiva una prueba de g++ libmudflap en el banco de pruebas:
sed -i -e /autogen/d -e /check.sh/d fixincludes/Makefile.in
mv -v libmudflap/testsuite/libmudflap.c++/pass41-frag.cxx{,.disable}
La documentación de GCC recomienda construirlo fuera del directorio de fuentes, en un directorio de construcción dedicado:
mkdir -v ../gcc-build
cd ../gcc-build
Prepara GCC para la compilación:
SED=sed \
../gcc-4.8.2/configure \
--prefix=/usr \
--enable-shared \
--enable-threads=posix \
--enable-__cxa_atexit \
--enable-clocale=gnu \
--enable-languages=c,c++ \
--disable-multilib \
--disable-bootstrap \
--with-system-zlib
Tenga en cuenta que para otros idiomas, hay algunos requisitos previos que no están disponibles. Ver el libro BLFS para obtener instrucciones sobre cómo construir todos los idiomas del CCG compatible.
El significado de la nueva opción de configure:
-
SED=sed
-
Establecer esta variable de entorno previene de una ruta modificable a /tools/bin/sed.
-
--with-system-zlib
-
Este modificador indica a GCC que vincule a la copia instalada del sistema de la biblioteca Zlib, en lugar de su propia copia interna.
Compila el paquete:
make
Importante
En esta sección, el banco de pruebas para GCC se considera crítico. No te lo saltes bajo ninguna circunstancia.
Se establece un conjunto de pruebas en el banco de pruebas de GCC para agotar la pila, por lo que se aumenta el tamaño de la pila antes de ejecutar las pruebas:
ulimit -s 32768
Comprueba los resultados, pero no para en los errores:
make -k check
Para recibir un resumen de los resultados de las pruebas, ejecuta:
../gcc-4.8.2/contrib/test_summary
Para obtener sólo un resumen, redirige la salida a través de grep -A7 Summ
.
Los resultados pueden compararse con los situados en http://www.linuxfromscratch.org/lfs/build-logs/7.5/
yhttp://gcc.gnu.org/ml/gcc-testresults/.
Unos fallos inesperados no siempre se pueden evitar. Los desarrolladores de GCC normalmente son conscientes de estos problemas, pero no los han resuelto todavía. En particular, las pruebas libmudflap son conocidas por ser particularmente problemáticas, como resultado de un error en GCC(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003).
A menos que los resultados de las pruebas son muy diferentes a los de la anterior URL, es seguro continuar.
Instala el paquete:
make install
Algunos paquetes esperan que el preprocesador de C esté instalado en el directorio / lib. Para apoyar a estos paquetes, crea un enlace simbólico:
ln -sv ../usr/bin/cpp /lib
Muchos paquetes usan el nombre cc para llamar al compilador de C. Para satisfacer a estos paquetes, crea un enlace simbólico:
ln -sv gcc /usr/bin/cc
Ahora que nuestras herramientas principales definitiva está en su lugar, es importante asegurarse una vez más que compilar y enlazar funcionará como se espera. Hacemos esto mediante la realización de las mismas comprobaciones de sanidad que usamos anteriormente en este capítulo:
echo 'main(){}' > dummy.c
cc dummy.c -v -Wl,--verbose &> dummy.log
readelf -l a.out | grep ': /lib'
Si todo funciona correctamente, no debe haber errores y la salida del último comando debe ser (con las diferencias para la plataforma sobre el nombre del enlazador dinámico):
[Requesting program interpreter: /lib/ld-linux.so.2]
Ahora asegúrese de que lo hemos configurado para usar los ficheros de inicio correctos:
grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log
Si todo funciona correctamente, no debe haber errores y la salida del último comando debe ser:
/usr/lib/gcc/i686-pc-linux-gnu/4.8.2/../../../crt1.o succeeded
/usr/lib/gcc/i686-pc-linux-gnu/4.8.2/../../../crti.o succeeded
/usr/lib/gcc/i686-pc-linux-gnu/4.8.2/../../../crtn.o succeeded
Dependiendo de la arquitectura de la máquina, lo anterior puede variar ligeramente, la diferencia suele ser el nombre del directorio después de /usr/lib/gcc. Si su máquina es un sistema de 64 bits, también puede ver un directorio llamado lib64 hacia el final de la cadena. La cosa importante a notar es que gcc haya encontrado los tres archivos crt *.o bajo el directorio /usr/lib.
Verifique que el compilador busca los archivos de cabecera correctos:
grep -B4 '^ /usr/include' dummy.log
Este mandato debe devolver con éxito con el siguiente resultado:
#include <...> search starts here:
/usr/lib/gcc/i686-pc-linux-gnu/4.8.2/include
/usr/local/include
/usr/lib/gcc/i686-pc-linux-gnu/4.8.2/include-fixed
/usr/include
Una vez más, tenga en cuenta que el directorio llamado después del triple-objetivo puede ser diferente a la anterior, en función de su arquitectura.
Nota
Desde la versión 4.3.0, GCC instala ahora incondicionalmente el archivo limits.h en un directorio privado incluido fijo, y se requiere que dicho directorio esté en su lugar.
A continuación, compruebe que el nuevo enlazador se está usando con la ruta de búsqueda correcta:
grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
Si todo funciona correctamente, no debe haber errores y la salida del último comando debe ser:
SEARCH_DIR("/usr/i686-pc-linux-gnu/lib")
SEARCH_DIR("/usr/local/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("/usr/lib");
Un sistema de 64 bits puede ver unos cuantos directorios más. Por ejemplo, aquí está la salida de una máquina x86_64:
SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib64")
SEARCH_DIR("/usr/local/lib64")
SEARCH_DIR("/lib64")
SEARCH_DIR("/usr/lib64")
SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib")
SEARCH_DIR("/usr/local/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("/usr/lib");
A continuación asegúrese de que estamos utilizando la libc correcta:
grep "/lib.*/libc.so.6 " dummy.log
Si todo funciona correctamente, no debe haber errores y la salida del último comando (permitiendo un directorio lib64 en 64 bits hosts) serán:
attempt to open /lib/libc.so.6 succeeded
Por último, asegúrese de que GCC utiliza el enlazador dinámico correcto:
grep found dummy.log
Si todo funciona correctamente, no debe haber errores y la salida del último comando debe ser (con las diferencias para la plataforma sobre el nombre del enlazador dinámico y un directorio lib64 en 64 bits hosts):
found ld-linux.so.2 at /lib/ld-linux.so.2
Si la salida no aparece como se muestra arriba, o no se recibe nada en absoluto, entonces algo está seriamente mal. Investiga y sigue los pasos para averiguar dónde está el problema y corregirlo. La razón más probable es que algo salió mal en el arreglo del fichero specs. Tendrán que ser resueltos antes de continuar con el proceso de cualquier problema.
Una vez que todo está funcionando correctamente, limpiar los ficheros de prueba:
rm -v dummy.c a.out dummy.log
Por último, mover un archivo fuera de lugar:
mkdir -pv /usr/share/gdb/auto-load/usr/lib
mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib